Conversation
This CL is a first step towards supporting new features and APIs of HDF5 v1.10. Right now, anecdotal evidence shows that HDF5 v1.8 is still massively deployed so support for 1.10 has to be opt-in, by way of an optional build tag aptly named "hdf5_v1.10" Updates gonum#16.
|
That looks good. And to confirm it even further. We are running this lib for quite some time now on HDF5 v1.10.1 without any issues. |
|
I am sure 1.10.x is great :) the issue is twofold:
I'd be inclined to say we support this PR was just for me to see how one could achieve support for 1.10.x w/o disturbing 1.8.x and lay some ground infra work down :) |
I don't think this is true. We could use an environment variable to choose which is installed and built against. |
| // #include "hdf5.h" | ||
| import "C" | ||
|
|
||
| // StartSWMRWrite enables SWMR writing mode for this file. |
There was a problem hiding this comment.
Is it worth adding this to the pre-1.10 being an error-returning noop?
| // Use of this source code is governed by a BSD-style | ||
| // license that can be found in the LICENSE file. | ||
|
|
||
| //+build hdf5_v1.10 |
There was a problem hiding this comment.
I think the convention more broadly has become // +build ....
You can use the matrix expansion support in Travis to build against different versions. Some references: |
4 participants
This CL is a first step towards supporting new features and APIs
of HDF5 v1.10.
Right now, anecdotal evidence shows that HDF5 v1.8 is still massively
deployed so support for 1.10 has to be opt-in, by way of an optional
build tag aptly named
"hdf5_v1.10"Updates #16.
Please take a look.